Broadband services amongst small businesses and home consumers are increasing at a rapid pace. Consistent with this trend is the proliferation of broadband devices which increase end users' capabilities and functionalities, e.g., voice over Internet Protocol (“VOIP”) devices.
With the availability of these expanded functionality devices comes complexity in terms of consumer integration of such devices into an already existing network, as the average consumer knows little about configuring a new device for an existing network. Thus, to date, new broadband device dissemination usually requires an extensive support staff (help desk) to assist end users in integrating these new devices into their network, as well as ensuring that previously existing network devices function as they did prior to the new addition.
This problem is exacerbated by the inclusion of a Dynamic Host Configuration Protocol (“DHCP”) server in new broadband devices. A DHCP server is typically included in new broadband devices as to provide any necessary routing; the assumption being that most homes simply have one personal computer (“PC”) connect to broadband gateway. A broadband device containing a DHCP server is typically referred to as a Network Address Translation Device or “NAT” device. The insertion of a NAT device (inserted to be directly connected to the gateway) into even a single PC environment places that single PC, which previously had a wide area network (“WAN”) addressable Internet Protocol (“IP”) address, outside the direct view of the WAN because the NAT device would have leased (given) the PC a private address upon request. Thus, for example, if the single PC was being used as a web server, such functionality would be inoperable after the insertion of the NAT device. Currently, the only way to resolve the above presented common scenario is for the end user to manually configure the newly inserted NAT device by means of port forwarding to the PC, for example. As many consumers are not network professional, this often results in complexity and frustration. Further, vendors of such NAT devices will most likely be required to provide some type of telephone or Internet help desk function to assist consumers in the above recited manual port forwarding configuration.
Another common scenario exists when a previously (“first”) NAT device already exists in the network and a new (“second”) NAT device is inserted between the broadband gateway and the first NAT device. Here, the second NAT device's inclusion would render the first NAT device, as well as all devices connected thereto, inoperable because the first NAT device would be invisible to the WAN. (A common reason as to why it be desirable to insert such a second NAT device in between the gateway and first NAT device is for bandwidth purposes. A VOIP NAT device is an example of such a second NAT device where this placement would be desirable.) Currently, the only way to resolve the above presented common scenario is to manually configure the second NAT device to port forward to the first NAT device. Again, as many consumers are not network professionals, this procedure often results in complexity and frustration. Further, again, vendors of such NAT devices will most likely be required to provide some type of telephone or Internet help desk function to assist consumers in the above recited manual port forwarding configuration.
What is needed is a device and method to easy the confusion and complexity of adding a new NAT device to a pre-existing network configuration.